Java® Virtual Machine (JVM) implementations support the Java® Native Interface (JNI) as a mechanism which allows Java® code to call methods written in C and C++ (native code) and vice versa. Traditionally both the code written in Java™ and the native code is executed in the same process and by the same thread as execution transitions between the two.
It is possible, however, to construct a JVM such that the native code is run in one or more Remote Execution Containers which may be hosted in separate processes on the same or different machines from where the Java® code is executed such that the native code is unaware that it is executing separately from the JVM. This separation prevents misbehaved native code from destabilizing the JVM and enables running the native code in a different environment (e.g., security context, bit width) than the main JVM.
In a split JVM the cost of the calls between Java® and native code have much greater overhead and latency resulting in the need to reduce round-trips where possible. With the standardized Java Native Interface (JNI) an application often has to make multiple calls to get the information needed to complete an action.
In a traditional JVM the overhead for a JNI to Java call is low enough to be acceptable. In the case of a distributed JVM, however, the latency of making a cross-process/cross-machine call may be magnitudes of order greater than required to run the method called. Because the Java Native Interface is standardized and all existing code needs to run in the Distributed JVM without modification, the option of changing the API to allow the application to request the data in a more efficient manner is not available. Therefore, the present disclosure recognizes that the number of round trips should be reduced to the minimum possible in a way that is transparent to the existing applications.
The distributed JVM concept is relevant in hybrid systems. Hybrid system in the present disclosure refers to a heterogeneous distributed system that contains both general and special-purpose computing platforms. One example is the zEnterprise system, which has system Z, X86 and Power7 blades, from International Business Machines Corporation (IBM®), Armonk, N.Y. Since hybrid systems could serve as a flexible platform for optimizing workload in terms of performance, more and more applications could benefit from running in hybrid systems.
JVM Proxy can accelerate Java® applications on hybrid systems by running a proxy JVM on a separate accelerator, which makes all Java® methods run on the accelerator and native methods run on the main machine. To improve application performance on JVM proxy, the present disclosure recognizes that native methods should be localized to run on accelerator, because a remote native method call initiated from a Java® method running on accelerator requires additional network round-trip overhead compared to the single system case. However, not all native methods can be localized. Checking if a native method can be localized by reading the source code manually requires much human cost. If a native method created newly or modified, such check needs to be made again.